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REMARKS 

In response to the Office Action mailed December 9, 2008, Applicant respectfully requests 
reconsideration. To further the prosecution of this application, amendments have been made in the 
claims, and each of the rejections set forth in the Office Action has been carefully considered and is 
addressed below. The claims as presented are believed to be in condition for allowance. 

Claims 1-12, 18-29, 35-45, 51-61 and 71-74 were previously pending in this application. 
Claims 1, 18, 35 and 51 are amended. No claims are added or canceled. As aresult, claims 1-12, 
18-29, 35-45, 51-61 and 71-74 remain pending for examination, with claims 1, 18, 35 and 51 being 
independent. No new matter has been added. 

Finality Of Office Action 

Initially, Applicant respectfully requests withdrawal of the finality of the Office Action, as 
the Office Action fails to state the grounds of rejection purportedly applicable to each of the rejected 
claims, as required by M.P.E.P. §706.07 and 37 C.F.R. §1.1 13(b). 

On p. 1, the Office Action indicates that the claims 1-12, 18-29, 35-45, 51-61 and 71-74 are 
rejected. On p. 2, the Office Action states that claims 1, 5, 6, 1 1, 22, 23, 28, 39, 40, 44, 61, 55, 56, 
3, 10, 20, 27, 37, 43, 53, 60, 4, 21, 38, 54, 7, 8, 12, 24, 25, 29, 41, 42, 45, 57, 58, 9, 26, 29, 59 and 
71-74 are rejected under 35 U.S.C. §102, and on p. 3, the Office Action states that claims 2, 19, 36 
and 52 are rejected under 35 U.S.C. §103. Thus, the Office Action fails to state any grounds for 
rejecting independent claims 18, 35 and 51. It is noted that the "details of the rejections" set forth in 
the last Office Action are incorporated by reference in the Final Office Action, the last Office 
Action did not reject claims 18, 35 or 51 under §102 or §103. 

M.P.E.P. §706.07 (quoting 37 C.F.R. §1.1 13(b)) states that "[i]n making [a] final rejection, 
the Office Action shall. . .state all grounds of rejection then considered applicable to the claims in 
the application, clearly stating the reasons in support thereof." As this explicit requirement has not 
been met, the finality of the Office Action is improper and should be withdrawn. 
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Claim Rejections Under 35 U.S.C. §102 

Claims 1, 5, 6, 1 1, 22, 23, 28, 39, 40, 44, 61, 55, 56, 3, 10, 20, 27, 37, 43, 53, 60, 4, 21, 38, 
54, 7, 8, 12, 24, 25, 29, 41, 42, 45, 57, 58, 9, 26, 29, 59 and 71-74 are rejected under 35 U.S.C. 
§ 102(e) as purportedly being anticipated by U.S. Patent No. 7,016,942 to Odom ("Odom"). Each of 
independent claims 1, 18, 35 and 51 is amended herein, and patentably distinguishes over Odom. 

I. Brief Overview Of Embodiments Of The Invention 

Embodiments of the invention relate generally to performing context management in a 
networked environment (see Applicant's specification at, e.g., p. 1, lines 5-6). In this respect, in 
certain settings, particular data entities, or "subjects," may be shared by multiple software 
applications. For example, users of applications in a healthcare setting commonly provide input 
relating to a particular patient to multiple applications (p. 1, lines 10-12). A user's input may 
include clinical data (e.g., x-ray images or blood work results), financial data (e.g., insurance 
coverage or billing history), or other data relating to the patient (p. 1, lines 12-14). 

Before context management systems were developed, users were forced to repeat the entry 
of data relating to the patient to each of the multiple applications (p. 1, lines 14-15). Context 
management systems provide the capability to manage a "context," which may include data 
describing one or more subjects (in this example, a patient) used commonly by the multiple 
applications (p. 1, lines 22-26). Thus, a user may switch from one patient's data to another within a 
first application, and all of the applications that share a context defined by the patient subject with 
the first application will switch to the other patient as well, to retain the context (p.3, line 24 - p.4, 
line 25). 

Patient data is only one illustrative example, as other data may define a subject, including 
data relating to a health care provider, clinical encounter, observation, insurer, user (e.g., to enable 
"single sign-on" capabilities for the multiple applications) and/or other data (p. 1, lines 15-19). 
Applications may also share a context defined by subjects not related to healthcare (p. 1, lines 15- 



1586111.1 



Application No. 10/632,673 

After Final Office Action of December 9, 2009 



14 



Docket No.: S1389.70013US00 



21). 

FIG. 1 depicts an exemplary context management system comprising context manager 230 
which manages a context for two context participant applications 210 and 220, which communicate 
with context manager 230 over a network (p. 2, lines 14-15). Applications 210 and 220 may 
execute on the same or separate computers, and these computers may be the same or separate from 
the computer(s) on which context manager 230 executes (p. 2, lines 16-18). . 

While the components of a context management system may communicate in different ways, 
in one example, when a user of one of the applications (e.g., application 210) desires to switch the 
context by accessing the data for a new subject (e.g., switching from one patient to another within 
the application), the application sends a request to context manager 230 (p. 3, lines 24-26). The 
requesting application may be referred to as the "instigator" of a requested change in context (p. 3, 
lines 28-29). When context manager 230 receives the request, it may survey the other applications 
that share the context (in this example, application 220) to determine whether the switch is 
acceptable (p. 3, lines 29-3 1). For example, context manager 230 may send a request to other 
applications that share the context, and these other applications may determine whether the change 
is acceptable (p. 4, lines 2-3). The context manager 230 may receive the results of the survey and 
communicate them to the instigator application (p.4, lines 12-16). The user of the instigator 
application may examine the results and determine how to proceed, such as by going forward with 
the change in context, cancelling it, or causing one or more applications to no longer share the 
context (p. 4, lines 12-16). 

Issues may arise when performing context management in a networked environment. For 
example, network security initiation of connection with (e.g., by facilities (e.g., virtual private 
networks (VPNs), firewalls, and/or other facilities) may prevent the transmission of unsolicited 
messages to) components executing on computers that reside "behind" the security facility (e.g., 
behind a firewall) (p. 12, lines 25-30). For example, a firewall may employ identity masking 
features which effectively allow a client residing behind the firewall to transmit messages to an 
outside device and to receive responses to those messages, but keeps the Internet Protocol (IP) 
address of the client hidden from the outside device so that the outside device can not transmit 
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unsolicited messages directly to the client (p. 12, lines 25-30). This may present a problem for 
context management systems, because if a context manager executes on a computer outside a 
firewall, it may be unable to initiate a connection with a context participant application executing on 
a client behind the firewall (p. 13, lines 1-3). Returning to the example above to illustrate, if 
application 210 executed on a client behind a firewall, and application 220 instigated a change in the 
context shared by applications 210 and 220, context manager 230 may be unable to survey 
application 210 because it may be unable to transmit an unsolicited message to application 210. As 
a result, applications 210 and 220 may be unable to share a context. 

Some embodiments of the invention provide techniques for facilitating communication 
between a client and a context manager. In one embodiment, a network connection is established 
between the client and context management server and maintained for a period of time during which 
a context is shared (p. 13, lines 4-7). 

The foregoing summary is provided to assist the Examiner in appreciating some aspects of 
the invention. However, the description above may not apply to each independent claim, and the 
language of each independent claim may differ in material respects from the summary provided 
above. Thus, Applicant's respectfully request that careful consideration be given to the language of 
each independent claim, and that each be addressed on its own merits, without relying on the 
summary provided above. In this respect, Applicant does not rely upon the summary above to 
distinguish any of the claims over the prior art, but rather only upon the arguments below. 

II. Claims 1-12, 18-29, 35-45, 51-61 and 71-74 

As amended, each of independent claims 1, 18, 35 and 51 includes limitations directed to a 
client executing at least one application which shares a context with another application for a period 
of time. A context management server is coupled to the client via a network. The network includes 
at least one security facility which prevents the context management server from initiating a 
connection with the client. A connection through the network is employed to transmit one or more 
communications between the context management server and the client to facilitate sharing of the 
context by the at least one client application and the another application. The connection is 
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maintained between the client and the context management server for the period of time during 
which the at least one client application and the another application share the context. 

Odom is simply unrelated to the subject matter of claims 1, 18, 35 and 51, as Odom says 
nothing at all relating to a plurality of applications sharing a context. In the "Response" section on 
p. 3, the Office Action contends that Odom discloses a plurality of applications sharing a context. 
Applicant respectfully traverses this assertion, as the word "context" is not used even once by 
Odom, and further points out that each of claims 1, 18, 35 and 51 requires that a context comprise at 
least one subject data item, usable by a plurality of applications, having a set of values comprising a 
first value corresponding to at least one client application and a second value corresponding to 
another application. Odom says nothing at all relating to these limitations. Instead, Odom discloses 
a system wherein a client computer may temporarily assume the responsibilities of a server 
computer to more effectively distribute processing resources or provide transactional privacy within 
a clustered competing environment (col. 1, lines 27-32). 

The Office Action also contends that the claimed subject matter does not address the 
problem summarized above relating to network security facilities preventing a context management 
server from transmitting unsolicited messages to applications residing behind a firewall, as the 
independent claims do not recite a network security facility. Each of claims 1, 18, 35 and 51 is 
amended herein to recite at least one network security facility which prevents a context management 
server from initiating a connection with a client. 

In view of the foregoing, each of claims 1, 18, 35 and 51 patentably distinguishes over 
Odom, such that the rejection of claim 1 under 35 U.S.C. § 102(e) as purportedly being anticipated 
by Odom should be withdrawn. 

Claims 2-12, 19-29, 36-45 and 52-61 depend from claims 1, 18, 35 and 51, respectively, and 
are allowable for at least the same reasons as the respective base claim. 
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CONCLUSION 

A Notice of Allowance is respectfully requested. The Examiner is requested to call the 
undersigned at the telephone number listed below to discuss any outstanding issues relating to the 
allowability of the application. 

If this response is not considered timely filed and if a request for an extension of time is 
otherwise absent, Applicant hereby requests any necessary extension of time. If there is a fee 
occasioned by this response, including an extension fee, the Director is hereby authorized to charge 
any deficiency or credit any overpayment in the fees filed, asserted to be filed or which should have 
been filed herewith to our Deposit Account No. 23/2825, under Docket No. S1389.70013US00. 



Dated: February 9, 2009 Respectfully submitted, 




Richard F. Giunta 

Registration No.: 36,149 

WOLF, GREENFIELD & SACKS, P.C. 

Federal Reserve Plaza 

600 Atlantic Avenue 

Boston, Massachusetts 02210-2206 

617.646.8000 
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